Generally, the present application relates to data processing. More specifically, the application is related to restricting access to resources accessible in a single sign-on (SSO) session.
Modern businesses rely on a variety of applications and systems that control and generate information that is critical to business operations. Different applications often provide different services and information, and different users may require access to different levels of information within each system or application. The level of access that users are granted may depend on the role of the user. For example, a manager may need access to certain information about employees that report to him, but it may be improper for that manager to access the same information about those whom he reports to.
Earlier less sophisticated applications incorporated access management business logic directly into the application code. That is to say, each application would require users to have a separate account, separate policy logic, and separate permissions, for example. Furthermore, when a user is authenticated by one of these applications, this authentication remains unknown to other applications in the enterprise because the fact that authentication with the first application has taken place is not shared. Thus, there is no concept of trust between applications using different systems for authentication and access control. Engineers quickly realized that having an access management system for each application in an enterprise was much like having a gas station for each car, and determined that authentication and access control would be more efficiently implemented and managed as a shared resource. These shared resources became known as an access management systems.
Access management systems often use policies and other business logic to make a determination regarding whether a particular access request should be granted to a particular resource. Upon making a determination that access should be granted, a token is provided to the requestor. This token is like a key that can be used to open a door that guards restricted data. For example, a user may attempt to access a human resources database to gather information about certain employees such as salary information. The user's web browser makes a request to the application, which requires authentication. If the web browser does not have a token, the user is asked to log in to the access management system. When the user is authenticated, the user's browser receives a cookie that represents a token that may be used to access the human resources application.
In an enterprise, users (e.g., employees) typically may have access to one or more different systems and applications. Each of these systems and applications may utilize different access control policies and require different credentials (e.g., user names and passwords). SSO can provide a user with access to multiple systems and applications after an initial login. For example, when the user logs-in to their work computer, the user can then also have access to one or more other resources, such as systems and applications.
In a situation where a user uses SSO to access resources from a shared computer, the user may want SSO access to a particular application only so as to prevent access to other resources accessible to that user for a SSO session. In other words, the user may not prefer to grant access to other resources besides a resource the user intends on accessing at that time. A first user may be concerned that a second user that uses the shared computer may access one or more of the resources accessible to the first user if a SSO session for the first user is active. Access management solutions may be challenged to provide users with the ability to configure access for a SSO session to restrict access to some of the resources accessible for the SSO session. Specifically, access management solutions are unable to allow users to choose at runtime the resources to which access is restricted for a SSO session.
Some access management solutions have been implemented to restrict access to some resources of the resources accessible to a user for a SSO session. For example, a session (e.g., an authentication session) is created to limit access to a specific resource the user is interested in accessing. However, such a solution depends on configuration of a specific authentication session. In another example, access to a specific resource may be configured for a lower authentication level that is permissible for users of a shared computer such that only those resources accessible to those users may be accessed. A resource would have to be designated ahead of time for restricting access. Such a solution may be unable to consider the access of different users that may potentially use a shared computer. Thus, the solutions in either of the examples do not enable a SSO session to be defined dynamically at runtime such that access to selected resources may be restricted.
New techniques are desired for enabling a user to dynamically (e.g., at run-time) select resources for which access is to be restricted for a single SSO session.